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Designing with microprocessors is a dy- 
namic activity. New applications of the 
device appear daily. And tomorrow’s pro- 
cessors will perform even more complex 
tasks. Microprocessor users must choose 
their design tools wisely to be able to take 
full advantage of the processors available 
today and those coming along. 

As microprocessor capabilities increase, 
the size and make-up of design teams will 
change. More extensive programming will 
be needed to effectively put these new 
capabilities to work. It is important that the 
design tools you choose today be adaptable 
to your design needs well into the future. 
The new Tektronix 8500 Modular Microcom- 
puter Development Lab Series is a design 
tool with such flexibility. 

Right now, there are three major ele- 
ments in the series: 

e The 8550 Microcomputer Development 
Lab (MDL), a self-contained, single-user 
system that supports 26 different chips, 
including the more popular 16-bit pro- 
cessors such as the Z8001, Z8002, 
68000, 8086, 8088, SBP9900, and 
TMSg9900. 

e The 8560 Multi-User Development Lab 
system, which contains a dedicated 
central computer and supports up to 
eight workstations. 

© The 8540 Advanced Integration Unit for 
performing hardware/software integra- 
tion in host computer environments. 


Fig. 1. The 8550 Microcomputer Development Lab is a versatile software development and hard- 
ware/software integration system for microprocessor-based product design. The system supports 


many popular 8- and 16-bit microprocessors. 


The 8560 can accommodate up to eight 
users with any combination of 8550s, 8540s 
or any RS232C terminals. Enhanced per- 
formance is achieved with the Tektronix 
CT8500 Terminal. 

The 8550 is available now, with the 8560 
and 8540 to follow within the year. 


The 8550 single-user system 

The 8550 Microcomputer Development Lab 
(figure 1) consists of two basic units — the 
8301 Microprocessor Development Unit and 
the 8501 Data Management Unit. Working 
together, these units support both software 
development and hardware/software 
integration. 

The 8301 Microprocessor Development 
Unit houses a system processor with 32K 
bytes of static system memory, 32K bytes 
of static program memory, a language pro- 
cessor, and an emulator controller. There 
is room for plug-in hardware options such 
as emulator processors, an additional 32K 
bytes of static program memory, a real-time 
prototype analyzer (RTPA), and a PROM 
programmer. The 8301 accommodates up 
to 16 plug-in circuit boards. 


Multiple processor architecture 

The 8301 uses a multiple-processor archi- 
tecture in a master-slave relationship (see 
figure 2), The system’s controller board, 
serving as the master processor, runs the 
operating system, directs the input/output 
([/O) activities for system peripherals, and 
directs all of the other system elements 
such as the emulator controller, language 
processor, PROM programmer, and emu- 
lator processors. 

The language processor operates as a 
slave to the system processor and trans- 
lates assembly language or high level lan- 
guage into machine language for the emu- 
lator processor. In addition, it runs the edi- 
tors including the high-performance ad- 
vanced CRT editor. 

The emulator processor, which is the 
same type as that to be used in the proto- 
type hardware under development, runs 
user programs and interfaces with the pro- 
totype hardware. Interaction between the 
system and emulator processors is con- 
trolled by the emulator controller under the 
direction of the system processor. The emu- 
lator controller ensures that only one pro- 
cessor has control of the system buses at 
any time. 
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Fig. 2. Functional block diagram of the 8301 Microprocessor Development Unit. The system uses 
a multiprocessor architecture in a master/slave arrangement. The system processor (in the 
system controller) serves as the master, with the emulator and language processors serving as 
slaves. A high-speed interface provides rapid data transfer between the 8301 and 8501 Data 


Management Unit. 


System bus structure 

The system bus in the 8301 is a 100-line 
bus structure that is common to all 16 plug- 
in circuit boards. The bus is essentially uni- 
versal in that data, address, and control 
lines are paralleled to all boards. The ex- 
ceptions are the independent debug and in- 
terrupt lines and some control lines for the 
system and emulator processors (see figure 
3). The separate lines result in a virtually 
uncrashable architecture. 


The memory structure 

In keeping with the multiprocessor concept 
of Tektronix systems, the 8301 memory is 
segmented, The system and program memories 
are identical 32K-byte static random- 
access memories (RAMs). The program 
memory is expandable to 64K bytes by 
adding a plug-in memory module. 

The system memory is accessed only by 
the system processor and contains DOS/50, 
the operating system. The main resident 
part of DOS/50 is transferred into system 
memory at start-up, with subroutines loaded 
from the system disc in the 8501 Data 
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Fig. 3. The system bus consists of 100 lines that provide connection to the plug-in circuit boards 
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Management Unit (DMU) as needed. The 
system memory also provides buffer space 
for I/O activities. 

The primary purpose of the program 


memory is to store the user program during 


execution by the emulator processor. The 
program memory also provides working 
space for the system and assembler pro- 


cessors, but only during program assembly 


and editing activities. During emulation, all 
program memory is available for the target 
microprocessor. 

The system processor has access to 


both system and program memories. Sever- 
al operating features are available to speed 


up the transfer of data between memories, 
including direct memory access (DMA), 


switching of 16K-byte blocks of data. A 
special high-speed interface port permits 
data transfer between the 8301 and 8501 
at a 153.6 kilobaud rate. 

Several emulation modes are avail- 
able: mode 0, mode 1, and mode 2 (see 
section on emulation capabilities). When 
operating in emulation mode 1, a memory 
map function is available that allows the 


operator to assign 128-byte blocks of mem- 


ory address space to either the program 
memory in the 8301 or the memory in the 
prototype hardware. Assignments can be 

made throughout a total address space of 
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in the 8301. The emulator controller board separates those control and signal lines that are 
dedicated either to the system section or to the program section. 


memory-to-memory data transfer, and bank 


64K bytes. This function also allows write 
protection to segments of program mem- 
ory, as selected by the user. 

The 8501 provides high-volume bulk stor- 
age up to two megabytes on two double- 
density, double-sided-disc compatible drives 
with DMA data transfers. A 32K by 16-bit 
dynamic RAM board provides temporary 
storage space for the file manager, device 
interrupts, and other functions. 

The 8501 also contains two 1K-byte 
read-only memories (ROMs). These ROMs 
contain a boot-up program for loading the 
operating system into system memory, 
and a set of self-test routines that are per- 
formed at start-up to ensure the 8550 is 
ready for use. 


The disc operating system 

The 8550 uses a new operating system 
called DOS/50 (for Disc Operating System, 
8550). While similar to TEKDOS (the oper- 
ating system for Tektronix 8001 and 8002 
MDLs) in many respects, DOS/50 provides 
several new options for arranging, manipu- 
lating, and protecting files and a number of 
enhanced debugging commands. 

DOS/50 supervises general input and 
output, file creation and maintenance, pro- 
gram assembly and compilation, program 
execution, monitoring and debugging, 
PROM programming, and communication. 

Optional software (such as assemblers) 
can be easily combined with DOS/50 on a 
master disc (which can store up to 1 mega- 
byte) giving you the convenience of having 
all of the assemblers, emulators, and com- 
pilers you would normally use, on one 
system disc. 

DOS/50 includes several other operating 
conveniences, such as spooling, which 
allows DOS/50 to send output to a line 
printer while performing other tasks; and 
type-ahead, which allows you to enter addi- 
tional commands while the previous com- 
mand is executing. 


File management 
The 8501 Data Management Unit handles 
files for DOS/50 and manages the move- 
ment of user files between its flexible discs 
and program memory in the 8301. 

Data management is simplified by using 
a tree-like file structure (see figure 4), which 
allows the user to specify one main system 
directory, one root directory for each disc, 
and any number of subdirectories under the 
root directory. Data files may be created 
and entered directly into the root directory. 


LIB aA LIBRARY 


ASM >a MAIN.MDL >= 
MAIN.MOLL >a 
MAIN.ASM >a 
MAIN.ASML> = 
MAIN.OBJ >a 
SUBASM >= 
SUB.ASML >= 
SUB.OBJ) >= 
LNKL >a 
LOAD >s 


Fig. 4. An example of the DOS/50 tree-like 
file structure. The “root” of the tree is at 

the top. The rectangles represent directories, 
while the squares represent data files. 
Arrows indicate a logical connection, from 
which a path can be designated with a file 
specification. 


As files are accumulated, the user may 
organize them into specific groups, each 
under its own specific directory. The user 
may create directories within directories 
to any level of nesting desired. 

With extensive nesting, the file specifica- 
tion needed to access a specific file can be 
lengthy and cumbersome to use. DOS/50 
includes a BRIEF command, which allows 
the user to specify a file by a single name. 
This greatly speeds up access to frequently 
used files. 

DOS/50 also includes an extensive set 


of file attributes that allow the user to desig- 


nate: the file owner, who can read from or 
write to that file, the date and time of file 
creation, when the file was last written to, 
when it was last accessed, and so forth. 
These attributes are especially helpful in 
keeping a file current when more than one 
user works with the file. 

The assembler software packages for 
the 8550 offer powerful macros, library 
generators, linkers, and other capabilities 
designed to enhance the user’s 
productivity. 


Emulation capabilities 

Integrating hardware and software is often 
the most time-consuming and frustrating 
task encountered in designing a micro- 
processor-based product. The 8550 emu- 
lator options allow integration in several 
stages, gradually transferring functions 
from the 8550 to the prototype. 


Three levels of emulation are available: 
© Mode 0, which uses the 8550's clock, 
program memory, and !/O signals to 
run the user’s program. The prototype 
hardware is not needed in this mode, 
allowing software debugging to take 
place before the prototype is 
operational. 
© Mode 1, (a partial emulation mode) uses 
the prototype’s clock and I/O services. 

Some emulators also allow use of the 

8550's I/O services in Mode 1. The pro- 

gram is run on the emulator, which may 

access both program memory and pro- 
totype memory. However, full control of 
the system is maintained by the system 
controller. A memory map function allows 
assignment of 128-byte blocks of memo- 
ry address space as previously discussed 
in the memory structure section. The 
emulator can operate at full speed using 
either program or prototype memory. 

© Mode 2, (the full emulation mode) uses 
only the prototype’s memory, clock, and 
1/O facilities and runs the user program 
under the emulator processor’s control. 

The user program can run at full speed, 

so any problems with functions involving 

critical timing relationships can be 
resolved. 

In modes 1 and 2, the emulator takes 
the place of the microprocessor that even- 
tually will reside in the prototype, using a 
prototype control probe to connect the pro- 
totype to the emulator. 

The prototype control probe is a critical 
link in the emulation system. The ideal emu- 
lator would be transparent to the prototype 
hardware. That is, the prototype would 
function as though the microprocessor 
were plugged directly into its socket on the 
prototype hardware. In Tek emulators, the 
microprocessor is mounted in the prototype 
control probe pod, close to the prototype 
microprocessor socket, thus substantially 
reducing the loading and propagation-time 
effects normally associated with emulators. 


The real-time prototype analyzer 

The optional real-time prototype analyzer 
(RTPA) enables the designer to locate criti- 
cal timing problems and hardware/software 
sequence problems in the prototype. The 
RTPA serves, in essence, as a logic ana- 
lyzer for all data, addresses, and access 
control on the prototype’s microprocessor 
socket. A logic probe provides an additional 
eight lines for viewing logic signals anywhere 
on the prototype board. 


